System and method for transferring a database from one location to another over a network

ABSTRACT

A client-server system for transferring a database from a server to a client across database types, vendors and without development effort. The system providing a server having access to a source database to be transferred to a client. The source database having metadata associated therewith including information regarding the structure and fields of the source database. The system including a client which communicates with the server through a network. The client having a data access application for processing the data received from the server and generating and populating a copy of the source database for use by the client.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to a prior U.S. provisionalapplication Serial No. 60/441,604 filed on Jan. 21, 2003 entitled“System and Method for Transferring Database from One Location toAnother”, which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The present invention relates generally to the transferring ofdatabases from one location to another over a network. In particular,the present invention relates to a client-server system for transferringan entire database including both the structure and content of thedatabase from a server to a client over the Web or general TCP/IPnetworks, without development effort and across database types, vendorsand operating systems.

BACKGROUND OF THE INVENTION

[0003] A feature of the Internet or World Wide Web, (WWW or Web) is theability to transmit electronic data files from one computer to anotherusing various types of file transfer protocols such as File TransferProtocol (FTP) and Hypertext Transfer Protocol (HTTP). Accordingly, theWeb has fundamentally changed the way people use data by making vastnumbers of documents readily available with little effort. The impact onproductivity has been dramatic.

[0004] A comparable, and perhaps more significant impact could berealized by enabling a similarly effortless exchange of business data.While many business systems perform well on their own, they tend to beisolated, so that the promise of end-to-end automation has not yet beenrealized. Ideally, all systems involved in a business process should beable to easily work together to perform a complete transaction. Forexample, an ordering system which may include sub-systems for inventory,shipping, billing, and receiving should be compatible for processing acomplete sales transaction. In such a system, all relevant sub-systemscould perform a complete end-to-end business process without humanassistance, resulting in dramatic productivity gains and significantshifts in the way business systems operate.

[0005] A barrier to improving the integration and automation in businesssystems is the lack of a simple and standard way to share business data.Web documents are well suited for use by individuals, but they are notnaturally or efficiently processed by business systems. It would be farmore effective to transfer business data, in its most natural form,(i.e., databases) directly into the business systems that use the data.

[0006] To achieve this goal using existing technology, business systemsmust conform to demanding and cumbersome Electronic Data Interchange(EDI) requirements, or programmers must develop transfer schemes on acase-by-case basis. There is no current standard for transferringbusiness data stored in databases from one location to another over anetwork without some development effort and/or prior knowledge of thedata to be transferred. Therefore, business processing has yet toexperience a revolution in productivity comparable to that resultingfrom the introduction and adoption of the document-centric Web in placetoday.

SUMMARY OF THE INVENTION

[0007] It is the general object of the present invention to provide asystem and method for transferring an entire database from one locationto another over a network without development effort, that improvesupon, or overcomes the problems and drawbacks associated with prior artdata transfer systems.

[0008] The present invention offers advantages and alternatives over theprior art by providing a client-server system for transferring an entiredatabase from one location to another over a network. The presentinvention database transfer system allows a client to copy a completedatabase, without development effort, including both the structure andcontents of the database regardless of the configuration of thedatabase, database type, vendor or operating platforms. The result isthe creation of a copy of a source database at a destination identifiedby the client so that business data may be shared among business systemsover the Web without a development effort in much the same way asdocuments are currently exchanged over the Web.

[0009] The present invention database transfer system in an exemplaryembodiment provides a client-server system having a server computer orserver connectable to a network and a client or client computerconnectable to the network for communication with the server. A sourcedatabase accessible to the server is provided for transfer to a client.The source database having data stored therein and metadata associatedtherewith identifying the structure and at least one field of the sourcedatabase. The client having a memory accessible thereto for storing acopy of the source database.

[0010] The server includes an executable program for accessing thesource database and retrieving the metadata and at least a portion ofthe data stored therein. The server providing for generating andexecuting queries to the source database for retrieving the metadata andthe stored data therefrom and storing the retrieved data in at least onedata object. The server then transfers the at least one data object tothe client. The client receives the at least one data object from theserver, extracts the metadata and uses it to generate a database withthe appropriate structure and tables and populates each table of thecopy of the database with the data from the corresponding data object.

[0011] In an alternative exemplary embodiment, for use with the transferof large databases, the database transfer system of the presentinvention provides a segmentation process for ensuring a database objecttransmitted to a client does not exceed a predetermined maximum sizedetermined by the maximum size of objects that can be serialized andsent over a network. Prior to transmitting a database object to a clientover a network the segmentation process determines whether the databaseobject exceeds a predetermined maximum object size. If the size of thedatabase object is greater than the maximum, the process truncates thedatabase object prior to transmission thereof to the client and storesthe truncated data in an auxiliary database object for subsequentforwarding to the client. The truncation can occur at any point in thedatabase, including the interior of a cell.

[0012] The present invention database transfer system provides astandardized system and method for the transfer of business data, namelydatabases, from one location to another over the Web or any TCP/IPnetwork. Presently, there is not a formal standard for storing andprocessing business data without a development effort. However, a verylarge number of business systems store business data in some type ofRelational Data Base Management System (RDBMS). Database data cannaturally serve as a common language (lingua franca) for most businesssystems currently in use, thus, the present invention database transfersystem can serve as a common means of business data exchange over theWeb without need of development effort.

[0013] Many RDMBS systems in use today come from different vendors andemploy different operating systems and interfaces. The present inventiondatabase transfer system uses existing standards to provide a commonframework for accessing database data from all major RDBMS systems andcomputer platforms. The system accesses and identifies the completestructure of a source database and retrieves its contents and convertsthe structure data and the contents of the database into a serial streamthat it sends over a network using the standard Transmission ControlProtocol/Internet Protocol (TCP/IP).

[0014] The serial data is received by an authorized client, whichcreates a new database with the appropriate structure and populates itwith data from the stream. The result is the creation of a copy of thesource database at a destination RDBMS chosen by the client. Thedatabase transfer can be performed over the Web or any TCP/IP networkand can be achieved by the client without development effort or evenexplicit software installation beyond commonly installed standardsoftware (e.g. Java-enabled Web browsers).

[0015] Additionally, the database transfer system provides for theincremental transfer of data between the server and client to maintainsynchronization of a transferred database at the client with a sourcedatabase.

[0016] In another aspect, the client-server system of the presentinvention provides a Web based database utility for client viewing andmodifying database data across database types, vendors and platformswithout requiring the transfer of the entire database to the client.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 is an exemplary embodiment of a schematic block diagram ofa client-server system in accordance with the present invention shown atthe initiation of the transfer of a database from a server to a client;

[0018]FIG. 2 is a schematic block diagram of the client-server system ofFIG. 1 shown after the transfer of a database from a server to a client;

[0019]FIG. 3 is a schematic block diagram of a server in accordance withthe present invention;

[0020]FIG. 4 is a schematic block diagram of a client in accordance withthe present invention;

[0021]FIG. 5 is an exemplary embodiment of a schematic block diagram ofa database in accordance with the present invention;

[0022]FIG. 5a is a schematic block diagram of a data transfer object inaccordance with the present invention;

[0023]FIG. 6 is a flow chart of an exemplary overview of the databasetransfer process of the present invention;

[0024]FIG. 7 is an exemplary flow chart of a segmentation process of adatabase object in accordance with the present invention; and

[0025]FIG. 8 is an exemplary embodiment of a web browser user interfacein accordance with the present invention.

DETAILED DESCRIPTION

[0026] Referring to FIGS. 1 and 2, an exemplary embodiment of aschematic block diagram of a client-server system in accordance with thepresent invention is shown generally at 10. The client-server system 10includes a server system 12 having a DataPortal server or server 14, anda server database system 16. The client-server system 10 includes aclient system 18 which communicates with the server system 12 through anetwork 20. The client system 18 includes a client server (or client) 22and a client database system 24. FIG. 1 illustrates the client-serversystem 10 prior to the transfer of a source database 26 from the serversystem 12 to the client system 18. FIG. 2 shows the client-server system10 following the transfer of the source database 26 to the client system18. The database 27 shown in FIG. 2 is a copy of the source database 26generated and stored on the client system 18 in accordance with thepresent invention database transfer system.

[0027]FIG. 3 is a block diagram of one embodiment of a server 14according to the present invention. The server 14 includes a “commercialoff the shelf” (COTS) Web server 28 for communicating with the client 22over standard Web channels via a Web protocol such as Hypertext TransferProtocol (HTTP). Additionally, the server 14 includes a servlet engine30. In the illustrated embodiment the servlet engine 30 is a Javaservlet engine for processing Java applications. The server 14 alsoincludes a request processing application 32 for processing clientrequests. Also provided is a data access application 34 for accessing aserver accessible database system 16 and processing data retrieved froma source database 26 for transfer to the client 22. In the FIG. 3embodiment, the server 14 includes a Java DataBase Connectivity (JCBC)programming interface 36 coupled to the data access application 34 foraccessing the database system 16 via the Structured Query Language (SQL)standard. The request processing application 32 and the data accessapplication in this exemplary embodiment are written in the Javaprogramming language. Alternate programming interfaces can be providedfor use by the server 14 to interface a particular database server 16 ordatabase 26 depending on the type of database or data stored therein.

[0028]FIG. 4 is a block diagram of one embodiment of a client 22according to the present invention. As shown, the client 22 includes arequest processing application 40 for receiving and processing datarequests from a user being a human operator or program (not shown). Thetransfer of a source database 26 from the server 14 to the client 22 canbe initiated from a user request via a GUI (Graphical User Interface)application or programmatically via an HTTP request directed to theclient or using a DataPortal API module embedded in a custom usersystem. FIG. 8 shows one embodiment of a web browser user interface 29for use initiating the transfer of a source database to the client 22.Alternatively, as mentioned above, the client-server system 10 providesa functionality to allow a database transfer to be initiatedprogrammatically rather than interacting from a GUI.

[0029] The client 22 includes an object transfer application 42 forsending and receiving data to and from the server 14 via the network 20using the HTTP protocol. The client also includes a data accessinterface 44 and a JDBC programming interface 36. The data accessinterface 44 processes data received from the server 14 and using theJDBC interface 36 recreates a database 24 corresponding to the structureof the source database 26 and populates the database 27 with datareceived from the server 14 resulting in the database 27 being a copy ofthe source database 26 for use by the client 22.

[0030] The data access interface 44 may include a mapping configurationfile for providing data type mapping configurations for use as necessaryto support the configuration and mapping of the various data typesutilize by database vendors. The JDBC programming interface 36 utilizedby the client 22 to access the client database system 24 is the same asthat described above with respect to the server system 12. Alternateprogramming interfaces can be provided for use by the client tointerface a particular database server or database depending on the typeof database or data stored therein. The client applications for use inthe database transfer can be downloaded from the server 14 upon a promptfrom the server following a client request for a database transfer fromthe server. Additionally, the client application can be configured as abrowser plug-in and set to operate automatically when a databasetransfer is requested.

[0031]FIG. 5 is a block diagram of one embodiment of a source database26 according to the present invention. The source database 26 includesmetadata 48 associated with the source database that containsinformation describing the structure and contents of the source databaseincluding schema and catalog information for the source database. Themetadata 48 also includes a list of tables 50 of the source database 26including the table name 52, table references, and indexing forperformance improvement. Additionally, the metadata 48 includesinformation related to each of the tables 50 including, for each table,a list of columns 54 in the table and the data type stored in eachcolumn. The metadata 48 can also include information pertaining to therows 56 for each of the tables 50.

[0032]FIG. 5a illustrates the basic objects used by the server 14 tosend data to the client 22. Database transfer object 31 is a high levelobject that contains all other objects sent to the client 22 including adatabase structure object 33 that contains database and table structureinformation extracted from the metadata 48 for the source database 26.The database data object 35 contains actual table 50 data used forpopulating database tables. The session information object 38 is used toidentify session information between the server 14 and client 22 so thatinterrupted transfer sessions can retrieved and continued.

[0033] Referring to FIG. 6, the operation of the server 14 isillustrated generally at 60 and the operation of the client 22 showngenerally at 85. When a user at the client 22 (either a human operatoror a program) requests a database transfer at step 61, the clientgenerates a request to the server 14 at step 62 in the form of an HTTPrequest based on the source database 26 indicated by the requestingagent. The server 14 receives the client request at step 63 wherein therequest is validated to determine whether processing should continue.The client request can be in the form of a specified location of asource database 26 available for transfer to the client 22, e.g., aUniform Resource Locator (URL). At the server 14, the web server 28receives the client request and forwards the request to the requestprocessing application 32.

[0034] The request processing application 32 processes the requestincluding providing security screening for authorizing client access tothe requested source database 26. The security screening may includenumerous types of screening processes such as client authorization andor content specific authorization. Content specific authorization canprovide certain users access to only specified subsets of a database 26as opposed to an entire database. For example, in an employee database,a field containing employee salaries may be accessible to only certainmanagers wherein other users of the employee database may access otherfields of the database.

[0035] Upon successful validation of a client request the requestprocessing application 32 forwards the client request to the data accessapplication 34 for performing the requested transfer. If the request isdetermined not valid, the process ends at block 73.

[0036] Upon receipt of a validated client request, the server dataaccess interface 34 determines the required JDBC driver and loads it andgenerates queries for retrieving the metadata 48 from the sourcedatabase 26 as illustrated at steps 64 and 65 of the flow chart. Thequeries are transferred to the JDBC programming interface 36 forexecution on the source database 26. Depending on the type of the sourcedatabase 26 an appropriate JDBC interface 36 is selected and used toaccess the source database 26. Accordingly, the request processingapplication 32 is universal and need not be modified for use withnumerous types of databases 26. In the preferred embodiment, theclient-server system 10 is compatible with most Relational Data BaseManagement Systems (RDBMS) wherein the system of the present inventionoperates without further development or prior knowledge of a sourcedatabase 26 or data types stored therein.

[0037] Once the metadata 48 is retrieved from the source database 26,the request processing application 32 generates a database structureobject 33 as shown in FIG. 5a and stores the metadata 48 or dataextracted from the metadata therein (Step 65). The database structureobject 33 is stored in a database transfer object 31, which is used bythe server 14 to send data to the client 22 over HTTP. The databasetransfer object 31 is sent to the client 22 in step 66. Next in steps 68and 69 the request processing application 32 retrieves from the metadata48 the structure for each table 50 and from the source database 26 thedata stored in each table. In step 70 the data retrieved from each table50 is stored in a data object 35 corresponding to each table 50 that isgenerated by the data access application 34. Thus, for each table 50 inthe source database 26 there is a corresponding data object 35containing the data retrieved from the table 50. Each of these tableobjects is added to the database transfer object 31 in step 71.

[0038] Depending on the type of the source database 26, for each fieldor table 50 thereof, the metadata 48 includes sufficient informationdescribing the structure and content of each table. The metadata 48 foreach table 50 may include a table name 52, and information pertaining tothe columns of the table such as column names 54 and the data typestored therein.

[0039] In the preferred embodiment, the data in each of the tables 50 ofthe source database 26 is retrieved by forming and executing appropriateJDBC queries. Typically, all data from the table 50 can be retrievedusing a standard JDBC query such as: SELECT*FROM ‘Table Name’. Theexecution of this query returns a Java Result Set object. Using thecolumn information 54, retrieved from the data structure object 33, thedata access application 34 generates queries to retrieve the data fromeach column of the table 50. The retrieved data is converted to Javaobjects as appropriate (e.g. string, byte array, date . . . ) and storedin a database data object 35 generated for and corresponding to thetable 50.

[0040] When all tables 50 have been processed, and their database dataobjects 35 stored in a data transfer object 31, the data transfer objectis sent to the client 22 via HTTP over the network 20 at step 72.

[0041] In one embodiment of the client-server system 10, prior totransferring a database transfer object 31 to the client 22, the size ofthe database transfer object 31 is compared to a maximum size which is apredetermined practical limit for the size of a single object to beserialized and transmitted over an HTTP channel. If the size of thedatabase transfer object 31 is greater than the maximum, the databasetransfer object is truncated prior to the transfer thereof to the client22.

[0042]FIG. 7 shows a flowchart of an exemplary embodiment of thesegmentation process of the database transfer object 31 according to thepresent invention referred to generally by the reference numeral 77. Thesegmentation process starts at step 78 where a session identificationvalue is assigned to the current transfer process so that it can besuspended, saved, retrieved and continued at any point in the process.Processing proceeds at step 79 as shown in detail in FIG. 6. At decisionblock 80 a determination is made to detect if either all data has beenprocessed or the size of the database transfer object 31 to this pointis greater than a predetermined maximum. This determination is madeafter determining and adding the size of each cell (element within atable row 50). If all data has been processed or the resulting size ofthe database transfer object 31 is greater than the maximum allowedsize, the database transfer object 31, containing a database data object35 and session information object 38, is transmitted to the client 22 atblocks 81 and 82. The client 22 retrieves the database transfer object31 and extracts and saves the session information object 38 as indicatedat step 110. The client 22 extracts the database data object 35 andprocesses it to create and populate a database 27 as detailed in FIG. 6.If no more data is required, as determined in block 111, the clientprocess ends at block 113. Otherwise, the session information is used toform a request for more data and sent to the server 14 at step 112.

[0043] Once the latest database transfer object 31 has been sent to theclient 22, if all data has been processed, server 14 processing ends at84. If the decision at block 83 results in a determination that moredata needs to be transferred, the current server processing thread issuspended and its parent object is saved in a hash table indexed withthe session identification value. A request for more data is receivedfrom the client 22 at block 86. Upon receipt of a client request foradditional data, the segmentation process retrieves the sessionidentification value from the client request and uses it to retrieve thesuspended processing thread (steps 89 and 91) which is then reactivatedand processing continues as before at 79. This sequence is repeated asoften as necessary until all data has been processed and sent to theclient 22, at which point, the server 14 processing ends for the currentdatabase transfer.

[0044] Referring again to FIG. 6, at the client 22, the databasetransfer object 31 is received from the server 14 via the objecttransfer interface 42 as shown. At block 86, the JDBC driver requiredfor the target database 27 is selected and loaded from the server 14.The server stores all JDBC database drivers that may be required by theclient 22. At step 90, the data access interface 44 retrieves the nameof the source database 26 from the database structure object 33 andgenerates and issues instructions to create a database 27 if theunderlying database system allows this creation (step 92). A typicalinstruction to create such a database is: CREATE DATABASE databaseName.Some database servers do not allow the creation of a database in thisfashion. In this case, a database 27 (which may or may not be empty)must be created and exist in the client system prior to the databasetransfer. The object transfer process 42 will delete all existing tablesin the database 27 to prepare for new incoming ones.

[0045] At blocks 93 and 94, the client 22 receives the database dataobject 35 from the server 14. Next at decision block 96, the programdetermines whether or not all of the tables 50 have been processed bythe data access interface 44 based on the database transfer object 31received from the server 14. If not, a new table is generatedcorresponding to the next table 50 and stored in the database 27 (step98). The new table is generated including the appropriate columns 54based on information retrieved from the data structure object 33. Atstep 100, the new table is populated using the data from the data object35. Once all of the tables 50 are processed, the transfer ends at block102.

[0046] Following is a description on how the tables 50 are created,populated, and referenced in the database 27 according to one embodimentof the present invention. The client 22 processes all incoming tables 50one at time. For each table 50, the program retrieves the columnstructure 54 (number of columns, column names, and data format for eachcolumn) from the metadata 48 which resides inside the database structureobject 33. From this structure, a new table is created using a typicalinstruction such as:

[0047] CREATE TABLE “table_name”

[0048] (col_(—)1_name col_(—)1_type(col_(—)1_type_attribute)nullSetting,

[0049] col_(—)2_name col_(—)2type(col_(—)2_type_attribute) nullSetting,

[0050] .

[0051] .

[0052] .

[0053] col_n_name col_n_type(col_n_type_attribute) nullSetting)

[0054] For string types, some binary types, and some numeric types, thetype attribute specifies how many characters, bytes, or digits thiscolumn can hold for each entry. If the type attribute is not needed, thecolumn type attribute and its surrounding parenthesis are absent. Allcolumn entries are assumed to be able to be set to null and nullSettingis normally left blank. If the column entry must have some value, thenullSetting is set to NOT NULL.

[0055] One at a time, the table 50 is then populated with data retrievedfrom the database data object 35. To speed up the data populatingprocess, for each table 50, the data access interface 44 at the clientissues data insertion instructions to the database server using amechanism called a prepared statement. In this mechanism, a template foran insertion command is issued to the database server with a questionmark in place of each of the columns of the table. The database serverwill compile this insertion command and awaits the incoming values forthe columns of each row. A typical prepared statement is as follows:

[0056] INSERT INTO “tableName” (col_(—)1_name, col_(—)2_name, . . . ,col_n_name)

[0057] VALUES (?, ?, . . . , ?)

[0058] The number of question marks in the template command above equalsthe number of columns. Once the prepared statement is issued, valuescorresponding to the columns are just filled in the proper order withoutthe insertion command being re-issued or re-compiled. This fastinsertion process continues until all rows 56 of the table 50 areprocessed and the table 50 is totally populated.

[0059] When all tables 50 have been created and populated, referencesbetween the tables are added to complete all data tables. The clientdata access interface 44 then proceeds to create the views. Views can bethought of as virtual tables, where all data are obtained from actualdata tables. Views are how data across tables can be grouped togetherand presented in any desirable way to the user. The view bodies, whichshow how they are created, are retrieved from the database structureobject 33. Once retrieved, the whole body can be issued to the databaseserver and the views are created. Once created, users can examine allcolumns of views as if they are data tables. Since tables and views maybe interdependent, the dependencies must be determined and tables andviews must be created in the appropriate order so as not to conflictwith dependency requirements.

[0060] Additionally the client-server system 10 of the present inventionprovides functionality for the incremental transfer of database databetween the server 14 and the client 22 to maintain synchronization of aclient database 27 with the source database 26. After an initialtransfer (described above), resulting in the creation of a clientdatabase 27 that represents a copy of the source database 26, the server14 can incrementally update the database 27 to reflect any changesapplied to the source database 26 since the previous client databaseupdate. Alternatively, such an incremental update can be initiated bythe client 22 to retrieve any changes to the source database 26 sincethe previous transfer (complete or incremental).

[0061] In one embodiment of the client-server system 10, an incrementaltransfer process is implemented by maintaining a column in each table 50where the latest modification time for each row 56 is stored as atimestamp. The latest timestamp for a client database transfer is alsomaintained. All data modified since the last client database transfercan be retrieved using a SQL query utilizing the timestamp columns andsent to the client to perform an incremental update, resulting in are-synchronization of the client database 27 with the source database26.

[0062] Additionally, the client-server system 10 provides a Web basedgeneral database utility for viewing and modifying database data acrossdatabase types, vendors and platforms. The server 14 provides a Webbased user interface (not shown) wherein a user can identify a selectedsource database 26 and/or request a search within the identified sourcedatabase 26. The server 14 converts the client request internally to astandard DataPortal (client-server system 10) form as described abovefor accessing the source database 26 and retrieving the requested datatherefrom. The retrieved data is converted to serial object formincluding data structure objects 33 and database data objects 35 asnecessary and transmitted to the client 22 as described above. Theclient upon receipt of the data objects (33, 35) extracts the datatherefrom using the above described methods and displays the appropriatecolumns, rows, tables, database, etc. as necessary for client viewingand modification of the requested data.

[0063] All data modified or updated by a client user is then returned tothe server 14 wherein the server generates the appropriate SQLstatements including the modified data and updates the source database26 accordingly.

[0064] The client-server system 10 ensures a high level of dataintegrity throughout the process of transferring data over the network20 between a server 14 and client 22 as follows. The transferred data isbroken down into a hierarchy of objects as described above, each ofwhich is serialized and sent over the network 20 using strict networkprotocols, including HTTP. When objects are received by the client 22,the parent class of each object is verified, and the objects areinstantiated and populated. Each of these steps imposes additional dataintegrity checks upon the transferred data. Only after each of thetransferred objects have been recreated on the client 22, the processingproceeds. Accordingly, the transfer process requires that all objectsconform to strict templates and any deviation from expectations willcause an error that will be reported to the server 14. Much of this dataintegrity enforcement is inherent in the Java language. Java constantlychecks for data integrity at many levels and reports any detectedproblems programmatically through its exception handling mechanism. IfJava reports any material exceptions to the system, the entire databasetransfer is terminated and, the database transfer in progress is removedand the process is restarted from the beginning.

[0065] In addition to the inherent integrity enforcement imposed by Javaas described above, the client-server system 10 provides a further dataverification process that utilizes row checksums. As the databasestructure objects 33 and database data objects 35 containing databasedata and structure are being built by the server 14, the size of thedata for each database data object 35 is calculated, in part, to limitthe size of objects that are serialized and transferred to the client,as described above in the segmentation process illustrated in FIG. 7.Additionally, if the data verification process is implemented, the rowsize in data bytes of each row of the tables 50 that are sent to theclient 22 is calculated and sent along with the table data to theclient. As the client recovers the data and uses it to build andpopulate database tables, it tracks the size in data bytes of each rowit adds to the database. This size is compared to the size calculatedand transferred by the server 14. Any discrepancies in row size for eachtable 50 will be detected and treated as a material exception, resultingin an error and the termination of the current database transfer. Thedatabase 26 in progress is removed and the transfer process is restartedagain from the beginning.

[0066] While exemplary embodiments have been shown and described,various modifications and substitutions may be made thereto withoutdeparting from the spirit and scope of the invention. Accordingly, it isto be understood that the present invention has been described by way ofillustration and not limitation.

What is claimed is:
 1. A client-server system for transferring adatabase from a server to a client, the system comprising: a serverconnectable to a network, the server having a memory accessible thereto;a source database accessible to the server having data stored therein,the source database having metadata associated therewith identifying astructure and at least one field of the source database; a clientconnectable to the network for communication with the server, the clienthaving a memory accessible thereto for storing a copy of the sourcedatabase; the server accesses the source database and retrieves themetadata and at least a portion of the data and stores the retrieveddata in at least one data object, each data object corresponding to afield of the database; the server sends the metadata and the at leastone data object to the client; the client receives the metadata and theat least one data object from the server and generates and stores a copyof the database using the metadata, and populates the copy of thedatabase with the data from the at least one data object; and whereinthe client-server system provides for the transfer of a source databaseto the client across various database types, vendors and operatingsystems without development effort.
 2. The client-server systemaccording to claim 1 wherein the server further comprises a data accessapplication which includes an executable program for generating andexecuting queries to the database for retrieving the metadata and thedata therefrom and storing the retrieved data in at least one dataobject, each data object corresponding to a field of the database. 3.The client-server system according to claim 1 wherein the metadataincludes at least one of: a database identifier; a list of tables storedin the database; a list of columns for each table; and a data type foreach column.
 4. The client-server system according to claim 1 whereinthe database is a relational database.
 5. The client-server systemaccording to claim 4 further comprising a database server coupled to thedatabase.
 6. The client-server system according to claim 2 wherein thedata access application further comprises a programming interface foraccessing the database.
 7. The client-server system according to claim 6wherein the programming interface is a Java DataBase Connectivity (JDBC)component.
 8. The client-server system according to claim 5 wherein thedatabase server further comprises a Relational DataBase ManagementSystem (RDBMS).
 9. The client-server system according to claim 1 whereinthe client further comprises a Relational DataBase Management System(RDBMS).
 10. The client-server system according to claim 1 wherein thenetwork is the Internet and the client is a Java applet executed on aJava enabled web-browser.
 11. The client-server system according toclaim 10 wherein the Java applet is downloadable from the server to theclient.
 12. The client-server system according to claim 1 wherein thedatabase to be copied is identified in a request from the client using aUniform Resource Locator (URL).
 13. The client-server system accordingto claim 12 wherein the copy of the database is generated in response tothe execution of a GUI function.
 14. The client-server system accordingto claim 2 wherein the server further comprises a web-server forcommunicating with the client.
 15. The client-server system according toclaim 14 wherein the data access application stores the metadata in astructure object and the structure object and the at least one dataobject in a database object and transfers the database object to theweb-server for transfer thereof to the client.
 16. The client-serversystem according to claim 15 wherein the web-server serializes thedatabase object prior to the transfer thereof to the client.
 17. Theclient-server system according to claim 1 wherein the server furthercomprises a request processing application for validating client accessto a requested database or portion thereof.
 18. The client-server systemaccording to claim 14 wherein the web-server communicates with theclient via Hypertext Transfer Protocol (HTTP).
 19. The client-serversystem according to claim 1 further comprising an incremental transferprocess for maintaining synchronization between the source database andthe copy of the source database residing on the client system.
 20. Theclient-server system according to claim 1 further comprising a Web basedutility for client viewing and modifying database data in a sourcedatabase, the utility operable across database types, vendors andoperating systems.
 21. The client-server system according to claim 1further comprising a data verification process for verifying theintegrity of the data objects transferred to the client over thenetwork.
 22. A data access application for use in transferring adatabase from a server to a client, the database having data storedtherein and associated metadata identifying a structure and at least onefield of the database, the data access application comprising anexecutable program for: retrieving from the database the metadata and atleast a portion of the data stored therein; storing the retrieved datain at least one data object, each data object corresponding to a fieldof the database; transferring the metadata and the at least one dataobject to the server for transfer thereof to the client; wherein thedata access application operates without further development acrossdatabase types, vendors and operating systems.
 23. The data accessapplication according to claim 22 further comprising an executableprogram for: storing the metadata in a structure object; converting theretrieved data to string objects and storing the string objects in theat least one data object; storing the structure object and the at leastone data object in a database object; and transferring the databaseobject to the server for transfer thereof to the client.
 24. The dataaccess application according to claim 22 further comprising a JavaDataBase Connectivity (JDBC) interface for accessing the database andretrieving therefrom the metadata and at least a portion of the datastored therein.
 25. A method for transferring a database from a serverto a client, the method comprising the steps of: at a server: providinga source database having data stored therein, the source database havingmetadata associated therewith identifying a structure and at least onefield of the database; accessing the source database and retrieving themetadata and at least a portion of the data stored therein; storing theretrieved data in at least one data object, each data objectcorresponding to a field of the database from which the data stored inthe data object was retrieved; sending the metadata and the at least onedata object to a client; the server operating on the source databaseacross various database types, vendors and operating systems withoutrequiring development effort; at a client: receiving the metadata andthe at least one data object; generating a copy of the source databaseaccording to the metadata; populating the copy of the source databasewith data retrieved from the at least one data object.
 26. The method ofclaim 25 further comprising: at the server: storing the metadata in astructure object; storing the structure object and the at least one dataobject in a database object; serializing the database object; andtransferring the database object to the client.
 27. The method of claim25 further comprising: at the server: comparing a size of the databaseobject to a maximum size prior to the transfer thereof to the client;and if the size of the database object is greater than a maximum size,segmenting the database object and separately transferring each of thesegments to the client.
 28. The method of claim 27 further comprising:at the server: generating an auxiliary object for storing the segmentsof the database object exceeding the maximum size prior to the transferthereof to the client.
 29. The method of claim 25 further comprising: atthe server: querying the source database for retrieving the metadata andthe data stored therein.
 30. The method of claim 29 further comprising:at the server: providing a programming interface for accessing andquerying the source database.
 31. The method of claim 25 furthercomprising: at the server: validating a client for authorization toaccess the source database or a portion thereof prior to accessing thesource database.
 32. The method of claim 25 further comprising:maintaining synchronization between the source database and the copythereof residing on the client.
 33. The method of claim 25 furthercomprising: providing a Web based utility for client viewing andmodifying the source database.